As computers have become more prevalent around the world, the need for different versions of operating systems or applications optimized or localized for different languages and/or locales has increased, as have the overhead costs associated with producing, updating and maintaining the large amount of such diverse versions. An operating system typically comprises code, data, and language-specific UI resources together in a single binary entity, such that modification of any portion requires an update to the whole. Thus, an update, such as pursuant to a security patch, must be provided for each language of interest. This is referred to as “localization,” with each resultant version being referred to as a “localized” version. Since, in the majority of cases when a change is required, the change occurs in the code portion and not the language specific portions, it is wasteful and costly to produce separate localized versions of most fixes, updates, etc. Moreover, when a rapid update response is necessary, such as in issuing a security fix, the delay caused by the need to produce many different specifically localized versions of the fix can leave users unprotected for an unacceptable period of time. Often in such situations, users in low priority locales bear the brunt of the delay since localized versions for higher priority locales are typically produced first.
One solution would be to separate the language independent code and data from language specific data such that modifications, including security patches and the like, could be made only to the language independent code and data. In such a manner, a single security patch could be quickly and efficiently developed and distributed worldwide, and yet still allow the manufacture of localized versions of operating systems and applications unchanged. Such a solution is described in more detail in application Ser. No. 10/435,848, entitled “Bifurcated Operating System Having a Language Neutral Component”, filed on May 12, 2003, the disclosure of which is hereby incorporated by reference in its entirety.
Unfortunately, a solution that provides for separate language neutral components and language specific components can quickly result in an unmanageably large number of files for even relatively simple applications that are only being localized for relatively few markets. Even a simple application with approximately 500 component files can require over 5000 corresponding language specific component files only to localize the application for the European market. Such a large number of files can significantly decrease the ability of new versions or patches to be efficiently compiled and distributed. In addition, and more significantly, a large number of files can adversely impact the performance of the application or operating system by requiring two or more files to be loaded: a language neutral file and one or more language specific files. Furthermore, additional resources must be expended to guard large numbers of files against security breaches or other malicious code. Finally, because many modern operating systems allocate virtual memory at a 64 kilobyte granularity and physical memory at a 4 kilobyte granularity, loading a large number of files that are smaller than 64 kilobytes will waste and fragment virtual memory. Files smaller than 4 kilobytes will have a further negative effect as they will impact both virtual and physical memory. It is not uncommon that an operating system will have a non-trivial amount (i.e., greater than 400) of files less than 4 kilobytes in size.